Cryptographically concealing amounts and asset types for independently verifiable transactions

ABSTRACT

Systems and methods are described for encrypting amounts and asset types of a verifiable transaction on a blockchain ledger. For each asset, an asset tag is blinded, multiplied by the amount of the asset, and the product is blinded again to create an encrypted amount of the asset. Both encrypted amount of the asset and a corresponding generated output value are within a value range, and the sum of the encrypted input value and the encrypted output value equals zero. Rangeproofs for each of the encrypted output values are associated with a different public key. Each public key is signed with a ring signature based on a public key of a recipient. A second ring signature is used to verify each asset tag, where the private key of the second ring signature for each asset is a difference between a first blinding value and an output coefficient.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/457,523, filed Feb. 10, 2017, and is also a continuation-in-part ofU.S. patent application Ser. No. 15/176,833, filed Jun. 8, 2016, whichclaims the benefit of U.S. Provisional Application No. 62/172,684, filedJun. 8, 2015, each of which are incorporated herein in their entirety.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document including anypriority documents contains material that is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent document or the patent disclosure,as it appears in the Patent and Trademark Office patent file or records,but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

One or more implementations relate generally to digitalcryptocurrencies, and more specifically systems and methods ofencrypting amounts and asset types for transactions in a digitalcryptocurrency ledger such the transaction's validity may still beverified by the network using publicly available information.

SUMMARY OF THE INVENTION

Systems and methods are described for encrypting amounts and asset typestransacted on a blockchain ledger while preserving the transaction'sability to be verified. Building upon confidential transactionsdescribed in related application U.S. patent application Ser. No.15/176,833, encrypted amounts of any desired number of encrypted assettypes may be transacted while preserving the identity of the parties tothe transaction. A processor may receive a first amount of a first assetand a second amount of a second asset to be transacted. Each asset mayhave an associated asset tag, the associated asset tags being uniformlyrandom elliptic curve points whose discrete logarithms are not knownwith respect to each other. A first blinding value may be added to eachasset tag being transacted to create blinded asset tags for each asset,the blinded asset tags being uniformly random elliptic curve points. Ablinded asset amount for each asset may be obtained by multiplying thefirst amount by the first blinded asset tag and the second amount by thesecond blinded asset tag. Encrypted amounts of each asset may then becreated by adding, for each received asset, a second blinding value toeach blinded asset amount. An output value corresponding to the inputvalue may then be generated and encrypted to create an encrypted outputvalue. The encrypted output value may include an output blinding amountsuch that the first blinding value and the output value blinding amountof an asset cancel each other out when added together. Both the receivedamounts and the generated output values for each asset may be set tofall within a value range, the value range being defined so that a sumof any two values within the range does not exceed an overflowthreshold, and such that a sum of the encrypted amounts and encryptedoutput values for each asset equals zero.

To further assist verification of the amounts of the transaction, aplurality of rangeproofs may be generated for each received asset,wherein different rangeproofs are associated with each of the generatedoutput values. The rangeproofs may show that the value associated witheach rangeproof falls within the value range, and each rangeproof may beassociated with a different public key. Each public key may becryptographically signed with a first ring signature based on a publickey of a recipient in the transaction, thereby encrypting the pluralityof rangeproofs. To optimize memory usage, a single memory amount may beshared among each public key.

To further assist verification of the asset types, differences betweenthe output values and the received amounts of each asset may begenerated. These differences for each asset may be signed with a secondring signature that has a difference between the first blinding valueand an output coefficient as a private key, which encrypts thedifferences for each asset into an asset surjection proof. The encryptedreceived amounts, the encrypted output values, the first ring signaturesand the second ring signatures may then be stored in a block, the blockbeing published on a blockchain where it may be subsequently verified.

Further described are systems and methods for performing verification ofan encrypted transaction having a plurality of different assets on ablockchain ledger. For each asset type, the encrypted received amount,the encrypted output value, first ring signature, and second ringsignature are received in a block appended to the blockchain. Theencrypted received amount and the encrypted output value are extractedfrom the received block. The encrypted received amount, as describedabove, includes an amount received of an asset, a blinded asset tagassociated with the asset type and a second blinding value. The blindedasset tag includes a first blinding value, and the encrypted outputvalue includes an associated blinding amount. The transaction isverified if the sum of the encrypted input value and the encryptedoutput value is zero, and the transaction is denied verification if thesum of the encrypted input value and the encrypted output value is anonzero value.

In an embodiment, the amount transacted on the blockchain ledger may bedecrypted (e.g., by a recipient of the amount transacted) by firstretrieving the block from the blockchain. The ring signature may begenerated using a private key (e.g., of the recipient), the ringsignature being associated with a correctly-valued public key for eachdigit of the encrypted input value. The correctly-valued public key maybe selected from a group of four public keys for each digit of theencrypted input value. An XOR operation may be applied to the smallestdigit of the ring encrypted input value, and the applying may berepeated for each digit. A repeated pattern within an output of the XORoperation may be identified. The positions of the repeated patternwithin the output of the XOR operation may then be used to determine theinput value from the encrypted input value.

In addition to the foregoing, improved rangeproof encoding systems andmethods for providing confidential transactions are described herein.Encrypted input values and output values as described above are createdby a processor. Each encrypted input value and output value is convertedinto a plurality of scalar values having a predetermined number ofdecimal places. A selected scalar may be set to zero, and the remainderof each plurality of scalar values may be normalized based on theoriginal value of the selected scalar, reducing the number of scalarvalues for both the input value and the output value by one (andcorrespondingly reducing the size of the rangeproof).

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings like reference numbers are used to refer tolike elements. Although the following figures depict various examples,the one or more implementations are not limited to the examples depictedin the figures.

FIG. 1 shows a flow diagram for a encrypting an amount transacted on ablockchain ledger, in an embodiment.

FIG. 2 shows a flow diagram for creating a ring signature for anencrypted input value, in an embodiment.

FIG. 3 shows a flow diagram for decrypting an input value from anencrypted input value signed with a ring signature, in accordance withvarious embodiments of the present invention.

FIG. 4 shows a flow diagram for verifying an encrypted transaction on ablockchain, in accordance with various embodiments of the presentinvention.

FIG. 5 is a block diagram of an exemplary system used for encryptingtransaction values on a blockchain in accordance with variousembodiments of the present invention.

FIG. 6 shows a flow diagram for encrypting an amount transacted on ablockchain using a modified rangeproof, in an embodiment.

FIG. 7 shows a flow diagram for encrypting different amounts ofdifferent asset types transacted on a blockchain ledger, in anembodiment.

FIG. 8 shows a flow diagram for an issuance transaction on a blockchaincreating a new asset class, in an embodiment.

FIG. 9 shows a flow diagram for verifying an encrypted transaction on ablockchain involving different asset types, in an embodiment.

FIGS. 10A-B show simplified block diagrams of a chain of digitalsignatures of a plurality of transactions and a proof-of-work system,respectively, according to various embodiments.

DETAILED DESCRIPTION

The security of conventional cryptocurrencies, such as a Bitcoin ledger,is based on universal verification: each participant individually andautonomously verifies that each transaction is valid, without trustingany third party. An unfortunate side effect is that all the transactiondata must be conspicuously public so it can be verified, which is atodds with the normal expectation of privacy for traditional monetaryinstruments. Insufficient financial privacy can have serious securityand privacy implications for both commercial and personal transactions.Without adequate protection, dishonest users can focus their efforts onknown high-value targets, competitors can learn business details, andnegotiating positions can be undermined. Since publishing often requiresspending money, lack of privacy can chill free speech. Insufficientprivacy can also result in a loss of fungibility—where some coins aretreated as more acceptable than others—which would further undermine acryptocurrency's utility as money.

Bitcoin partially addresses the privacy problem by using pseudonymousaddresses. If someone does not know which users own which addresses, theprivacy impact may be reduced. But any time a transaction is made with auser, at least one of that user's addresses becomes known to the otherparty of the transaction. From there, the other party could trace outother connected addresses and estimate the values of their transactionsand holdings. For example, suppose an employer pays an employee withBitcoin, and the employee later spends those coins on rent andgroceries. Both the employee's landlord and the supermarket would learnthe employees income (and could charge higher prices as the employee'sincome changes or target the employee for theft).

There are existing deployed techniques that further improve privacy inBitcoin (such as CoinJoin, which merges the transaction history of usersby making joint payments), but the utility of these techniques isreduced by the fact that it's possible to track amounts. There have beenproposed cryptographic techniques to improve privacy in Bitcoin-likesystems, but so far all of them may result in breaking “pruning” andresult in participants needing a perpetually growing database to verifynew transactions, because these systems prevent learning which coinshave been spent. Most proposed cryptographic privacy systems also havepoor performance, high overhead, and/or require new and very strong (andless well understood) cryptographic assumptions.

The systems and methods described herein improve the situation by makingthe transaction amounts private, while preserving the ability of thepublic network to verify that the ledger entries still add up. This maybe done without adding any new basic cryptographic assumptions to theBitcoin system, and with a manageable level of overhead. As aside-effect of its design, the additional exchange of private “memo”data (such as invoice numbers or refund addresses) may be allowed by thedescribed encryption methods, without any further increase intransaction size, by reclaiming most of the overhead of thecryptographic proofs used to make the transaction amounts private.

FIG. 1 shows a flow diagram 100 for a encrypting an amount transacted ona blockchain ledger, in an embodiment.

A processor may add a blinding amount to an input value being transactedto create an encrypted input value at step 110. To encrypt an inputvalue of a transaction, a particular type of commitment may be selectedthat preserves the additive property. A commitment scheme maintains datasecrecy but commits to the data so that it cannot be changed later bythe sender of the data. A simple commitment scheme can be constructedusing an exemplary cryptographic hash:commitment=SHA256(blinding_factor∥data)If a party only knows the commitment, then they cannot determine whatunderlying data values have been committing to (given certainassumptions about the properties of the hash). Both the data and theblinding factor may be revealed later, and a recipient of the commitmentcan run the hash and verify that the committed data matches the revealeddata. The blinding factor is present because without one, someone couldtry guessing at the data.

A Pedersen commitment works like the above but with an additionalproperty: commitments can be added, and the sum of a set of commitmentsis the same as a commitment to the sum of the data (with a blinding keyset as the sum of the blinding keys):C(BF1, data1)+C(BF2, data2)==C(BF1+BF2, data1+data2)C(BF1, data1)−C(BF1, data1)==0In other words, the commitment preserves addition and the commutativeproperty applies (i.e., the Pedersen commitment is additivelyhomomorphic, in that the underlying data may be manipulatedmathematically as if it is not encrypted. For example, given input datavalues data_n={1,1,2} and a blinding factor BF_n={5,10,15} then:C(BF1, data1)+C(BF2, data2)−C(BF3, data3)==0.In an embodiment, Pedersen commitments used to encrypt the input valuemay be constructed using elliptic curve points. Conventionally, anelliptic curve cryptography (ECC) pubkey is created by multiplying agenerator for the group (G) with the secret key (x):Pub=xG.The result may be serialized as a 33-byte array. ECC public keys mayobey the additively homomorphic property mentioned before with respectto Pedersen commitments. That is:Pub1+Pub2=(x1+x2 (mod n))G.

The Pedersen commitment for the input value may be created by picking anadditional generator for the group (H, in the equations below) such thatno one knows the discrete log for second generator H with respect tofirst generator G (or vice versa), meaning no one knows an x such thatxG=H. This may be accomplished, for example, by using the cryptographichash of G to pick H:H=to_point(SHA256(ENCODE(G))).Given the two generators G and H, an exemplary commitment scheme toencrypt the input value may be defined as:commitment=xG+aHHere x may be the secret blinding factor, and a may be the input valuebeing committing to. The Pedersen commitments areinformation-theoretically private: for any commitment, there exists someblinding factor which would make any amount match the commitment. ThePedersen commitments may be computationally secure against fakecommitment, in that the arbitrary mapping may not be computed. If thecommitment may be computed, it means that the discrete log of G and Hwith respect to one another are known, which means that the security ofthe group is compromised.

Accordingly, the normal 8-byte integer amounts in Bitcoin transactionsmay be replaced by 33-byte Pedersen commitments in some embodiments. Anoutput value corresponding to the input value may be generated andencrypted (e.g. also using the Pedersen commitment described above) tocreate an encrypted output value at step 120. The encrypted output valuemay include a corresponding blinding amount, added at step 130, suchthat the input value blinding amount and the generated output valueblinding amount cancel each other out when added together. That is, ifthe sender of an asset in a transaction takes care in picking theblinding factors so that they add up correctly, then the network canstill verify the transaction by checking that its commitments add up tozero:(In1+In2+In3+plaintext_input_amount*H. . . )−(Out1+Out2+Out3+ . . .fees*H)==0.Verification using the Pedersen commitment may require making the feesin a transaction explicit. However, this may be desirable

Unfortunately, without additional measures, a Pedersen commitment alonemay be insecure. The problem is that the group is cyclic, and additionis mod P (a 256-bit prime number that defines the order of the group).As a result, addition of large values can ‘overflow’ and behave likenegative amounts. This means that a sums-to-zero behavior still holdswhen some outputs are negative, effectively allowing the creation of 5coins from nothing: (1+1)−(−5+7)==0 This would be interpreted as “auserspends two bitcoins, gets a ‘−5’ bitcoin out that they discard out,and a 7 bitcoin output,” thereby allowing a malicious user to causecurrency inflation.

In order to prevent this, when there are multiple outputs a proof isused to show that each committed generated output is within a valuerange which cannot overflow (e.g. [0, 2{circumflex over ( )}64]). Boththe input value and the output value being transacted may be valuesfalling with the value range, the value range being defined so that asum of any two values within the range does not exceed an overflowthreshold (e.g., the maximum possible value, such as 2{circumflex over( )}64). The value range may be set by the sender of the assetassociated with the input value in some embodiments.

Accordingly, a plurality of rangeproofs may be generated at step 140,wherein a different rangeproof is associated with each of the inputvalue being transacted and the generated output value. The rangeproofsmay prove that a committed amount is within the value range but revealnothing else about the value. If an ECC signature is constructed so thatthe ‘message’ is a hash of the pubkey, the signature may prove that thesigner knew the private key, which is a discrete log of the pubkey withrespect to some generator (like G or H discussed above). For a ‘pubkey’like P=xG+aH, no one knows the discrete log of P with respect to Gbecause of the addition of H, because no one knows an x for xG=H, exceptfor the edge case where the input value a is 0. If a is zero then P=xGand the discrete log is just x; someone could sign for that pubkey.

The rangeproofs may show that the value associated with each rangeprooffalls within the value range, and each rangeproof may be associated witha different public key, signed at step 150. Each public key may becryptographically signed with a ring signature based on a public key ofa recipient in the transaction, thereby encrypting the plurality ofrangeproofs. To avoid giving away the input value being transacted, aring signature may be used. A ring signature is a signature scheme wherethere are two (or more) pubkeys and the signature proves that the signerknows the discrete log of at least one of the pubkeys. The ringsignature together with the range proof may prove a commitment thatcommitment C is either 0 or 1—also known as an “OR proof”. First,commitment C to the input value is provided, and C is computed by arecipient of the input value (using a private key held by the recipient,which includes the blinding factor):C′=C−1H.Then a ring signature over {C, C′} is provided. If C was a commitment to1 then the recipient would not know its discrete log, but C′ becomes acommitment to 0 and the recipient would know its discrete log (just theblinding factor, known by the recipient). If C was a commitment to 0,the recipient would know its discrete log, and would not know thediscrete log for C′. If C was a commitment to any other amount, none ofthe results of the ring signature would be zero and the recipient won'tbe able to sign to decrypt the encrypted input value. This works for anypair of numbers, just by suitably pre-processing the amounts that areput into the ring . . . or even for more than two numbers. For example,in a case where a sender wishes to generate a rangeproof showing thatcommitment C is in the value range [0, 32]. The sender may send therecipient a collection of commitments and OR proofs for each of them.Each commitment may be associated with a digit of the input value. Forexample, the following commitments may be included in a rangeproof:

C1 is 0 or 1 C2 is 0 or 2 C3 is 0 or 4 C4 is 0 or 8 C5 is 0 or 16.

If the sender selects the blinding factors for C1-5 correctly thenC1+C2+C3+C4+C5==C. Effectively the input value has been built in binary,and the resulting 5-bit number can only be in the range [0,32].

Numerous optimizations may make rangeproof generation more efficient. Tooptimize memory usage, a single memory amount may be shared among eachpubkey. For example, a Borromean ring signature may be used, which isespecially efficient: it requires only 32 bytes per pubkey, plus 32bytes which can be shared by many separate rings. The Borromean ring mayhave twice the asymptotic efficiency of previously proposedconstructions for this application. In a further embodiment, eachrangeproof may include a plurality of component values, where eachcomponent value is a base ten exponent. That is, instead of expressingthe amount directly in binary, encrypted amounts may be expressed usinga decimal floating point where the digits are multiplied by a base 10exponent. This means that large amounts may be proven with relativelysmall proofs, so long as they have few significant digits in base 10:e.g., 11.2345 and 0.0112345 can have the same size proof, even thoughone number is a thousand times larger. The ring signature may further beassociated with a leftover amount that is not scaled by an exponent insome embodiments. In embodiments using base ten, for example, numbersless than ten would not be scaled by an exponent. The number less thanten could be expressed as a non-private “minimum amount” sent, whichallows a smaller proof to cover a larger range if the user doesn't mindleaking some information about the minimum amount (which might alreadybe public for external reasons); this also allows the least significantdigits to be non-zero when an exponent is used. Minimum amounts may besupported by first subtracting the minimum, then proving that the resultis non-negative.

FIG. 2 shows a flow diagram for an exemplary method 200 for creating aring signature for an encrypted input value. In the exemplary embodimentof method 200, referred to herein as a Borromean ring signature, theinput value is rewritten into base four at step 210. The mantissa of thefloating point may be encoded using rings of size 4 (base 4) rather thanbinary, because this may minimize the number of commitments sent whilenot using any more signature data than base two. The final mantissadigit commitment can be skipped, backwards constructing it from thevalue being proven and the other digits, etc.

Each digit in the rewritten input value may be assigned to a ring atstep 220, where each ring has four public keys corresponding to possiblevalues of the digit. Each digit may be encrypted using a digit-specificblinding factor at step 230, and a potential value for the digit may beassigned to a public key for that digit. The ring signature may then begenerated using a private key at step 240, the ring signature beingassociated with a correctly-valued public key for each digit. Returningto FIG. 1, the encrypted input value, the encrypted output value, andthe encrypted rangeproofs may be stored in a block at step 160. Theblock may then be published on a blockchain, where it may besubsequently verified. FIG. 4 shows a flow diagram for an exemplarymethod 400 for verifying an encrypted transaction on a blockchain. Theencrypted input value, the encrypted output value, and the encryptedrangeproofs are received in a block appended to the blockchain at step410. The encrypted input value and the encrypted output value may beextracted from the received block at step 420. As described above, theencrypted input value may include the input value being transacted and ablinding amount. The encrypted output value may also include anassociated blinding amount. The transaction is verified at step 430 ifthe sum of the encrypted input value and the encrypted output value iszero. Likewise, the transaction is denied verification if the sum of theencrypted input value and the encrypted output value is a nonzero valueat step 440. Accordingly, the transaction may be verified as a validtransaction, where the inputs equal the outputs, without a verifieractually knowing the amounts transacted.

As for the recipient of the asset having the input value, the inputvalue may be decrypted using a private key held by the recipient. FIG. 3shows a flow diagram for an exemplary method 300 for decrypting an inputvalue from an encrypted input value signed with a ring signature. Theblock may be retrieved from the blockchain at step 310. The ringsignature, generated during the encryption process may be regeneratedusing a private key (e.g., of the recipient) at step 320. The ringsignature may be associated with a correctly-valued public key for eachdigit of the encrypted input value, in addition to a plurality ofincorrectly-valued public keys for each digit. The correctly-valuedpublic key may be selected from a group of, for example, four publickeys for each digit of the encrypted input value. An XOR operation maybe applied to each digit of the ring-encrypted input value, startingwith the smallest digit, at step 330. The applying the XOR operation maybe repeated for each digit of the encrypted input value. A repeatedpattern within an output of the XOR operation may be identified at step340. The positions of the repeated pattern within the output of the XORoperation may then be used to determine the input value from theencrypted input value at step 350.

Finally, by careful use of derandomized signing in the proof, it'spossible for the receiver of the coins—who shares a secret with thesender, due to ECDH key agreement with the receivers pubkey—to ‘rewind’the proof and use it to extract a message sent by the sender, which maybe up to 80% of the size of the proof. The message may be used, forexample, to provide the value and blinding factor to the receiver, butcould also be used to include information like reference numbers orrefund addresses. The result is that a proof for a 32-bit value is 2564bytes, and simultaneously may convey 2048 bytes of message. A 32-bitproof can cover a range of 42.94967296 BTC with 1e-8 precision, or429.4967296 BTC with 1e-7 precision, and so on. The implementationsupports proofs of any mantissa size or exponent, with the parameterscontrolled by the sender. Performance and size may be linear in thenumber of mantissa bits, and odd numbers of bits are supported (byswitching to radix-2 for the last digit). In some embodiments, therangeproofs are only required in cases where there are multipleconfidential value outputs (including fees). Transactions that mergemultiple confidential amounts into a single output may not need rangeproofs, since the fact that all the inputs were in range may providesufficient protection against overflow.

FIG. 5 is a block diagram of an exemplary system for providing a peggedsidechain in accordance with various embodiments of the presentinvention. With reference to FIG. 5, an exemplary system forimplementing the subject matter disclosed herein, including the methodsdescribed above, includes a hardware device 500, including a processingunit 502, memory 504, storage 506, data entry module 508, displayadapter 510, communication interface 512, and a bus 514 that coupleselements 504-512 to the processing unit 502.

The bus 514 may comprise any type of bus architecture. Examples includea memory bus, a peripheral bus, a local bus, etc. The processing unit502 is an instruction execution machine, apparatus, or device and maycomprise a microprocessor, a digital signal processor, a graphicsprocessing unit, an application specific integrated circuit (ASIC), afield programmable gate array (FPGA), etc. The processing unit 502 maybe configured to execute program instructions stored in memory 504and/or storage 506 and/or received via data entry module 508.

The memory 504 may include read only memory (ROM) 516 and random accessmemory (RAM) 518. Memory 504 may be configured to store programinstructions and data during operation of device 500. In variousembodiments, memory 504 may include any of a variety of memorytechnologies such as static random access memory (SRAM) or dynamic RAM(DRAM), including variants such as dual data rate synchronous DRAM (DDRSDRAM), error correcting code synchronous DRAM (ECC SDRAM), or RAMBUSDRAM (RDRAM), for example. Memory 504 may also include nonvolatilememory technologies such as nonvolatile flash RAM (NVRAM) or ROM. Insome embodiments, it is contemplated that memory 504 may include acombination of technologies such as the foregoing, as well as othertechnologies not specifically mentioned. When the subject matter isimplemented in a computer system, a basic input/output system (BIOS)520, containing the basic routines that help to transfer informationbetween elements within the computer system, such as during start-up, isstored in ROM 516.

The storage 506 may include a flash memory data storage device forreading from and writing to flash memory, a hard disk drive for readingfrom and writing to a hard disk, a magnetic disk drive for reading fromor writing to a removable magnetic disk, and/or an optical disk drivefor reading from or writing to a removable optical disk such as a CDROM, DVD or other optical media. The drives and their associatedcomputer-readable media provide nonvolatile storage of computer readableinstructions, data structures, program modules and other data for thehardware device 500.

It is noted that the methods described herein can be embodied inexecutable instructions stored in a non-transitory computer readablemedium for use by or in connection with an instruction executionmachine, apparatus, or device, such as a computer-based orprocessor-containing machine, apparatus, or device. It will beappreciated by those skilled in the art that for some embodiments, othertypes of computer readable media may be used which can store data thatis accessible by a computer, such as magnetic cassettes, flash memorycards, digital video disks, Bernoulli cartridges, RAM, ROM, and the likemay also be used in the exemplary operating environment. As used here, a“computer-readable medium” can include one or more of any suitable mediafor storing the executable instructions of a computer program in one ormore of an electronic, magnetic, optical, and electromagnetic format,such that the instruction execution machine, system, apparatus, ordevice can read (or fetch) the instructions from the computer readablemedium and execute the instructions for carrying out the describedmethods. A non-exhaustive list of conventional exemplary computerreadable medium includes: a portable computer diskette; a RAM; a ROM; anerasable programmable read only memory (EPROM or flash memory); opticalstorage devices, including a portable compact disc (CD), a portabledigital video disc (DVD), a high definition DVD (HD-DVD™), a BLU-RAYdisc; and the like.

A number of program modules may be stored on the storage 506, ROM 516 orRAM 518, including an operating system 522, one or more applicationsprograms 524, program data 526, and other program modules 528. A usermay enter commands and information into the hardware device 500 throughdata entry module 508. Data entry module 508 may include mechanisms suchas a keyboard, a touch screen, a pointing device, etc. Other externalinput devices (not shown) are connected to the hardware device 500 viaexternal data entry interface 530. By way of example and not limitation,external input devices may include a microphone, joystick, game pad,satellite dish, scanner, or the like. In some embodiments, externalinput devices may include video or audio input devices such as a videocamera, a still camera, etc. Data entry module 508 may be configured toreceive input from one or more users of device 500 and to deliver suchinput to processing unit 502 and/or memory 504 via bus 514.

The hardware device 500 may operate in a networked environment usinglogical connections to one or more remote nodes (not shown) viacommunication interface 512. The remote node may be another computer, aserver, a router, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the hardware device 500. The communication interface 512 mayinterface with a wireless network and/or a wired network. Examples ofwireless networks include, for example, a BLUETOOTH network, a wirelesspersonal area network, a wireless 802.11 local area network (LAN),and/or wireless telephony network (e.g., a cellular, PCS, or GSMnetwork). Examples of wired networks include, for example, a LAN, afiber optic network, a wired personal area network, a telephony network,and/or a wide area network (WAN). Such networking environments arecommonplace in intranets, the Internet, offices, enterprise-widecomputer networks and the like. In some embodiments, communicationinterface 512 may include logic configured to support direct memoryaccess (DMA) transfers between memory 504 and other devices.

In a networked environment, program modules depicted relative to thehardware device 500, or portions thereof, may be stored in a remotestorage device, such as, for example, on a server. It will beappreciated that other hardware and/or software to establish acommunications link between the hardware device 500 and other devicesmay be used.

It should be understood that the arrangement of hardware device 500illustrated in FIG. 5 is but one possible implementation and that otherarrangements are possible. It should also be understood that the varioussystem components (and means) defined by the claims, described above,and illustrated in the various block diagrams represent logicalcomponents that are configured to perform the functionality describedherein. For example, one or more of these system components (and means)can be realized, in whole or in part, by at least some of the componentsillustrated in the arrangement of hardware device 500. In addition,while at least one of these components are implemented at leastpartially as an electronic hardware component, and therefore constitutesa machine, the other components may be implemented in software,hardware, or a combination of software and hardware. More particularly,at least one component defined by the claims is implemented at leastpartially as an electronic hardware component, such as an instructionexecution machine (e.g., a processor-based or processor-containingmachine) and/or as specialized circuits or circuitry (e.g., discretelogic gates interconnected to perform a specialized function), such asthose illustrated in FIG. 5. Other components may be implemented insoftware, hardware, or a combination of software and hardware. Moreover,some or all of these other components may be combined, some may beomitted altogether, and additional components can be added while stillachieving the functionality described herein. Thus, the subject matterdescribed herein can be embodied in many different variations, and allsuch variations are contemplated to be within the scope of what isclaimed.

In the description that follows, the subject matter will be describedwith reference to acts and symbolic representations of operations thatare performed by one or more devices, unless indicated otherwise. Assuch, it will be understood that such acts and operations, which are attimes referred to as being computer-executed, include the manipulationby the processing unit of data in a structured form. This manipulationtransforms the data or maintains it at locations in the memory system ofthe computer, which reconfigures or otherwise alters the operation ofthe device in a manner well understood by those skilled in the art. Thedata structures where data is maintained are physical locations of thememory that have particular properties defined by the format of thedata. However, while the subject matter is being described in theforegoing context, it is not meant to be limiting as those of skill inthe art will appreciate that various of the acts and operation describedhereinafter may also be implemented in hardware.

For purposes of the present description, the terms “component,”“module,” and “process,” may be used interchangeably to refer to aprocessing unit that performs a particular function and that may beimplemented through computer program code (software), digital or analogcircuitry, computer firmware, or any combination thereof.

It should be noted that the various functions disclosed herein may bedescribed using any number of combinations of hardware, firmware, and/oras data and/or instructions embodied in various machine-readable orcomputer-readable media, in terms of their behavioral, registertransfer, logic component, and/or other characteristics.Computer-readable media in which such formatted data and/or instructionsmay be embodied include, but are not limited to, physical(non-transitory), non-volatile storage media in various forms, such asoptical, magnetic or semiconductor storage media.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in a sense of “including,but not limited to.” Words using the singular or plural number alsoinclude the plural or singular number respectively. Additionally, thewords “herein,” “hereunder,” “above,” “below,” and words of similarimport refer to this application as a whole and not to any particularportions of this application. When the word “or” is used in reference toa list of two or more items, that word covers all of the followinginterpretations of the word: any of the items in the list, all of theitems in the list and any combination of the items in the list.

While one or more implementations have been described by way of exampleand in terms of the specific embodiments, it is to be understood thatone or more implementations are not limited to the disclosedembodiments. To the contrary, it is intended to cover variousmodifications and similar arrangements as would be apparent to thoseskilled in the art. Therefore, the scope of the appended claims shouldbe accorded the broadest interpretation so as to encompass all suchmodifications and similar arrangements.

As described above, some cryptocurrencies, such as Bitcoin, with notrusted issuer or transaction processor, use a publicly verifiabledistributed ledger (i.e., a blockchain). The blockchain may includeevery transaction since its establishment, resulting in a final state,the unspent transaction output set (UTXO set), which describes theamounts and owners of all coins.

Each UTXO contains an amount and a verification key; transactionsdestroy UTXOs and create new ones of equal or lesser total amount, andmust be signed with the keys associated to each destroyed UTXO. Thismodel allows all users to verify transaction correctness withouttrusting any payment processor to be honest or reliable. However, thismodel has a serious cost to user privacy, since every transaction ispreserved forever, exposing significant amounts of information directlyand indirectly.

One conventional technique to obscure transaction structure is used byCoinJoin, which allows users to interactively combine transactions,obscuring which inputs map to which outputs. However, becausetransaction amounts are exposed, it is difficult to use CoinJoin in sucha way that these mappings cannot be recovered, at least in a statisticalsense. In particular, unless all output amounts are the same, they aredistinguishable and may be grouped.

One solution to the exposure of transaction data is described above inFIG. 1, which blinds the amounts of all outputs, while preserving publicverifiability of the fact that the total output amount is equal to thetotal input amount. Each explicit UTXO amount is replaced by ahomomorphic commitment to the amount; since these amounts arehomomorphic over a finite ring rather than the set of integers, arangeproof is attached to each output to prevent attacks related tooverflow. The text below describes various improvements and expansionsto the confidential transactions described above.

First, a space optimization of the underlying ring signature used inFIG. 1 is described. Then a new scheme, confidential assets, isdescribed that further supports multiple asset types within singletransactions. Public verifiability that no assets are created ordestroyed is preserved, while hiding both the output amount(s) and theoutput asset type(s).

It would be desirable for blockchain technologies to support multipleasset types on the same chain. This may permit a wider set of users toshare the security properties of the same chain, and also enables newuse cases, such as multi-asset transactions which effect atomicexchanges. One could create support for multiple asset types bylabelling each transaction output with a publicly visible “asset tag”;however, this would expose information about users' financial behavior.Confidential Assets (CA) is a technology to support multiple asset typeswith blinding of asset tags, which builds on the privacy benefits of theconfidential transactions described above and extends the power andexpressibility of blockchain transactions. Confidential Assets allowsanybody to cryptographically verify that a transaction is secure: thetransaction is authorized by all required parties and no asset isunexpectedly created, destroyed, or transmuted. However, only theparticipants in the transaction are able to see the identity of assettypes involved and in what amounts.

First, a space-optimized rangeproof will be described. FIG. 6 shows aflow diagram for an exemplary method 600 off encrypting an amounttransacted on a blockchain using a modified rangeproof. Schoenmakersdescribed a simple rangeproof of base-b digits using the conjunction ofzero-knowledge OR proofs of each digit. See Schoenmakers, B., Intervalproofs revisited (2005), slides presented at International Workshop onFrontiers in Electronic Elections, which is hereby incorporated byreference. The rangeproof described in FIG. 6 modifies the basicrangeproof concept in the following ways: the OR proofs are based onBorromean Ring Signatures, which allow sharing a random challenge acrossevery digit's proof, and one scalar is removed from each proof bychanging the commitment to each digit (without changing the digititself) while the proof is generated.

Rangeproofs are created by a processor for encrypted output values asdescribed in FIG. 1 at step 610. The creating may include splitting theoutput value into digits which sum to the encrypted output value. Eachrangeproof is converted into a plurality of scalar values having apredetermined number of decimal places at 620 (as described in therangeproofs above). In an embodiment, the created rangeproof may includea list of (unrelated) scalars, four scalars per digit. These scalars arepart of the signature and are public data (so the sense in which therangeproof is “converted” into scalars is simply that it is interpretedas a list of scalars). The bits (e.g., base 3/4 digits) are separatesecret scalars which are used to compute the ring signature but do notappear in the final signature. A selected scalar may be set to zero atstep 630 (e.g., the first scalar of the plurality), and the remainder ofeach plurality of scalar values may be normalized based on the originalvalue of the selected scalar, reducing the number of scalar values forboth the input value and the output value by one (and correspondinglyreducing the size of the rangeproof) at step 640. In the exemplaryembodiment having four scalars per bit, the remaining three scalars arerenormalized before being added to the block on the ledger.

Consider a Pedersen commitment scheme with generators G, H, and let H:C->M be a random oracle hash.

Verify (C, π = {e₀, (C⁰, s₁ ⁰, s₂ ⁰, . . . , s_(m−1) ⁰), . . . (C^(n−1),s₁ ^(n−1), . . . , s_(m−1) ^(n−1))}) works as follows: 1. For each i ∈{0, . . . , n − 1},  (a) Define e₀ ^(i) =e₀ for consistency of thefollowing equations.  (b) For each j ∈ {1, . . . , m − 1} compute  e_(j) ^(i) ← H (s_(j) ^(i) G − e_(j−1) ^(i) [C^(i) − jm^(i)H]) (1) (c) Compute R¹ ←e _(m−1) ^(i)C¹ 2. Compute ê₀ ← H ( R⁰ ∥ . . . ∥R^(n−1)). 3. Accept if  ê^₀ = e₀ ; and  C = Σ_(i)C^(i). Prove (v, r).Proving works as follows. 1. Write v in base m as v⁰ + v¹m + ... +v^(n−1)m^(n−1), (Note that superscripts on m are exponents whilesuperscripts on v are just superscripts.) 2. For each i ∈ {0, ... , n −1},  ${{(a)\mspace{14mu}{If}\mspace{14mu} v^{i}} = 0},\left. {{choose}\mspace{14mu} k_{0}^{i}}\overset{\mspace{11mu}\$\;}{\leftarrow}{Z_{q}\mspace{20mu}{and}\mspace{14mu}{set}\mspace{14mu} R^{i}}\leftarrow{K_{0}^{i}{G.}} \right.$ (b) Otherwise,   i. Choose    r^(i) uniformly randomly and compute C¹ ←Commit(m^(i)v^(i),r^(i)).   $\left. {{{ii}.\mspace{14mu}{Choose}}\mspace{14mu} k_{0}^{i}}\overset{\mspace{11mu}\$\;}{\leftarrow}{Z_{q}\mspace{20mu}{and}\mspace{11mu}{compute}\mspace{14mu} e_{v^{i}}^{i}}\leftarrow{H\;{\left( {k^{i}G} \right).}} \right.$  iii. For each    ${j \in \left\{ {{v^{i} + 1},\ldots,{m - 1}} \right\}},{{{choose}\mspace{14mu} s_{j}^{i}}\overset{\mspace{11mu}\$\;}{\leftarrow}Z_{q}},{{and}\mspace{14mu}{compute}\mspace{14mu} e_{j}^{i}}$   directly from equation (1). (If v^(i) = m − 1, this step is a no-op.)  iv. Compute R^(i) ← e_(m−1) ^(i)C^(i). 3. Set e₀ ← H(R⁰ ∥... ∥R^(n−1)). 4. For each i ∈ {0, ... , n − 1},  (a) If v^(i) = 0,   i. Foreach _(j) ∈ {1, ... , m − 1}, choose     $k_{j}^{i}\overset{\mspace{11mu}\$\;}{\leftarrow}Z_{q}$     e_(j) ^(i) ←H(k_(j) ^(i) + e_(j−1) ^(i)m^(i)jH)     taking e₀ ¹ = e₀.   $\left. {{{ii}\ .\mspace{14mu}{Set}}\mspace{14mu} C^{i}}\leftarrow\frac{R^{i}}{e_{m - 1}^{i}} \right. = {\frac{k_{0}^{i}}{e_{m - 1}^{2}}{G.}}$  ${{{{iii}\ .\mspace{14mu}{For}}\mspace{14mu}{each}\mspace{14mu} j} \in \left\{ {1,\ldots\mspace{14mu},{m - 1}} \right\}},\left. {{set}\mspace{14mu} s_{j}^{i}}\leftarrow{k_{j}^{i} + {\frac{k_{0}^{i}e_{j - 1}^{1}}{e_{m - 1}^{2}}.}} \right.$ (b) Otherwise,   ${{{{i.\mspace{14mu}{For}}\mspace{14mu}{each}\mspace{14mu} j} \in \left\{ {1,\ldots,{v^{i} - 1}} \right\}},{{{choose}\mspace{14mu} s_{j}^{i}}\overset{\mspace{11mu}\$\;}{\leftarrow}Z_{q}},{{and}\mspace{14mu}{compute}\mspace{14mu} e_{j}^{i}}}\;$   directly from equation (1) taking e₀ ¹ = e₀ (If v_(i) − 1 this is ano-    op.)   ii. Set s_(v) _(i) ^(i) = k^(i) + e_(v) _(i) ^(i) 1^(r)^(i) .$\left. {5.\mspace{14mu}{Set}\mspace{14mu} C}\leftarrow{\sum\limits_{i = 0}^{n - 1}{C^{i} \cdot {Output}}} \right.$  π = {e₀, (C⁰, s₁ ⁰, s₂ ⁰, ... , s_(m−1) ⁰), ... (C^(n−1), s₁ ^(n−1),s_(m−1) ^(n−1))}.The resulting rangeproof is nearly the same construction as BorromeanRing Signatures, except for the following two differences:

-   -   There are no s¹ ₀ values, which were used in the calculation of        ê₀ in the Borromean Ring Signature construction, saving i        scalars in the total proof.    -   The commitments C^(i) are no longer included in any hashes        (which is necessary when computing sub−commitments to the digit        (m−1), as seen in step 4(a)ii of the Prove algorithm above).        Unfortunately, the resulting construction may no longer be        secure in general; the proof of security may rely on all keys        being binding commitments rather than arbitrary public keys. The        ring signature may be signed, the rangeproofs may be completed        based on the adjusted scalar values, and the completed        rangeproofs may be stored with the encrypted output values in a        block on a ledger at step 650 (in the same manner as described        with respect to steps 150 and 160 of FIG. 1).

FIG. 7 shows a flow diagram for a method 700 of encrypting differentamounts of different asset types transacted on a blockchain ledger, inan embodiment. Up to now, we have considered a single asset (for exampleBitcoin) and transactions which move this asset from one holder toanother. Consider an extension of this scheme which supports multiplenon-interchangeable asset types (for example, Bitcoin and a US dollarproxy) within single transactions. This increases the value of the chainby allowing it to serve more users, and also enables new functionality,such as atomic trades of different assets. We could accomplish this byattaching to each output an asset tag identifying the type of thatasset, and having verifiers check that the verification equation holdsfor subsets of the transaction which have only a single asset type.(Basically, treating the transaction as multiple single-assettransactions, except that each input signs the entire aggregatetransaction.) This requires verification of multiple equations,increases complexity, and more importantly, gives chain analysts anadditional data point to consider, reducing the privacy of the users ofthe chain. This also could lead to censorship of transactions involvingspecific asset types, since all asset types are visible. We insteadpropose a scheme for which all asset tags are blinded, so that norelationship between output asset types can be inferred. This avoids theprivacy loss and greatly improves privacy by hiding the specific assetsused by individual transactions. This is especially important for assetswith low transaction volume where use of the asset alone is sufficientto identify users.

A processor may receive a first amount of a first asset and a secondamount of a second asset to be transacted at step 710. To describe thetechnology behind Confidential Assets (i.e. transactions with multipleasset types, such as the transaction shown in FIG. 7), it is useful tostart with Pedersen commitments that form the basis of ConfidentialTransactions:commitment=xG+aHwhere G is a standard generator of an elliptic curve and H is a secondgenerator for which nobody knows the discrete log with respect to G.Such a generator is referred to herein as a nothing-up-my-sleeve, orNUMS generator. To represent two different assets, the commitments maybe represented as:commitment_1=xG+aHcommitment_2=xG+aIIn such an example, H and I may represent two distinct assets, and thusthe two commitments shown, while committing to the same amount a, arecommitments to different assets. Each asset (e.g., assets H and I) mayhave an associated asset tag, the associated asset tags being uniformlyrandom elliptic curve points whose discrete logarithms are not knownwith respect to each other.

A first blinding value may be added to each asset tag being transactedto create blinded asset tags for each asset, the blinded asset tagsbeing uniformly random elliptic curve points, at step 710. The abovediscussion assumed every transaction output had a NUMS generator (i.e.,asset tag) associated with it, and that outputs of the same asset typewould use the same tag. This does not satisfy the privacy goal, becauseit is visible what type of asset every output represents. This can besolved by replacing each asset tag of a commitment with a blinded assettag of the form:A=H+rGHere H is an asset tag from above and r is the secret first blindingvalue. Anybody who knows r can tell what asset H the blinded tag Arepresents, but to anyone else it will appear to be a uniformly randomelliptic curve point. It follows that any commitment to a value with Ais also a commitment to the same value with H, so the “outputs minusinputs equals zero” rule from confidential transactions will continue towork when validating transactions:commitment_A=xG+aA=xG+a(H+rG)=(x+ra)G+aH=commitment_HAs shown below, the introduction of the first blinding factor does notaffect the user's ability to produce a rangeproof, though it does makethe algebra slightly more complicated when constructing the transactionto balance out to zero.

A blinded asset amount for each asset may be obtained by multiplying thefirst amount by the first blinded asset tag and the second amount by thesecond blinded asset tag. Encrypted amounts of each asset may then becreated by adding, for each received asset, a second blinding value toeach blinded asset amount at step 720. Step 720 logically follows fromthe discussion above, as the encrypted amount of asset H could beexpressed as the following commitment:commitment_1=xG+aAwhere a is the received amount of asset H, A is the blinded asset tag,and xG is the second blinding value.

An output value corresponding to the input value may then be generatedand encrypted to create an encrypted output value at step 730. Theencrypted output value may follow the same rules as the encrypted outputvalued described above with respect to FIG. 1. That is, the encryptedoutput value may include an output blinding amount such that the firstblinding value and the output value blinding amount of an asset canceleach other out when added together. Both the received amounts and thegenerated output values for each asset may be set to fall within a valuerange, the value range being defined so that a sum of any two valueswithin the range does not exceed an overflow threshold, and such that asum of the encrypted amounts and encrypted output values for each assetequals zero.

Consider now a complete transaction with two inputs of distinct assettypes and two outputs, like so:in1=xG+aH, H - -\ /- - uG+cH, H=out1| - - - |in2=yG+bI, I - -/ \ - - vG+dI, I=out2

In confidential transactions (described in FIG. 1), only one generatoris used, and to verify a transaction's validity, the following equationhad to have been satisfied:out1+out2−in1−in2=0which it would if and only if the transaction balanced. As it turns out,this same equation works even with multiple assets:

$\begin{matrix}{0 = {{{out}\; 1} + {{out}\; 2} - {{in}\; 1} - {{in}\; 2}}} \\{= {\left( {{uG} + {cH}} \right) + \left( {{vG} + {dI}} \right) - \left( {{xG} + {aH}} \right) - \left( {{yG} + {bI}} \right)}} \\{= {{\left( {u + v - x - y} \right)G} + {\left( {c - a} \right)H} + {\left( {d - b} \right)I}}}\end{matrix}$Since H and I are both NUMS points, the only way for this equation tohold is if each individual term is 0, and in particular, if c=a and b=d.In other words, this equation holds only if the total amount of asset His the same on the input side and the output side, and the total amountof asset I is the same on the input side and the output side. Thisextends naturally to more than two asset tags; in fact, it is possibleto support an unlimited number of distinct asset types, as long as eachone can be assigned a unique NUMS generator.

As in CT, the simple requirement that the inputs be canceled out by theoutputs is insufficient because it is possible for amounts to overflow,effectively allowing negative-valued output values. As in CT, this canbe solved by attaching a plurality of rangeproofs to each asset outputvalue at step 740, in exactly the same way as described above in FIGS. 1and 6 (either rangeproof schema may be used). The only difference isthat the verifier must use the appropriate asset tag in place of thefixed generator. Different rangeproofs are associated with each of thegenerated output values. The rangeproofs may show that the valueassociated with each rangeproof falls within the value range, and eachrangeproof may be associated with a different public key. Each publickey may be cryptographically signed with a first ring signature based ona public key of a recipient in the transaction at step 750, therebyencrypting the plurality of rangeproofs exactly as the CT transactiondescribed above in FIG. 1. To optimize memory usage, a single memoryamount may be shared among each public key.

To further assist verification of the asset types, differences betweenthe output values and the received amounts of each asset may begenerated. These differences for each asset may be signed with a secondring signature that has a difference between the first blinding valueand an output coefficient as a private key at step 760, which encryptsthe differences for each asset into an asset surjection proof. The useof asset surjection proofs may be advantageous for the followingreasons. Since every blinded asset tag looks uniformly random, how canverifiers be sure that the underlying asset tags are legitimate? Itturns out that the “sum to zero” rule is not sufficient to preventabuse. For example, consider the “blinded asset tag”A′=−H+rGAny amount of the blinded asset A′ will actually correspond to anegative amount of asset H, which an attacker could use to offset anillegal increase of the money supply (similarly to using a negativeoutput amount). To solve this problem, an asset surjection proof isused. The asset surjection proof is a cryptographic proof that within atransaction every output asset type is the same as some input assettype, while blinding which outputs correspond to which inputs. Forexample, if A and B are blinded asset tags (e.g., for an encrypted inputvalue and an encrypted output value) which commit to the same asset tagH say, thenA−B=(H+aG)−(H+bG)=(a−b)Gmay be used as a signature key with corresponding secret key a-b (wherea is the first blinding value coefficient for the received amount of theasset and b is an output coefficient used to blind the output value forthe asset). Given a transaction output out1, a second ring signature(proof that one of several secret keys is known that keeps secret whichone) may be generated with the keys being the differences between theoutput values and the received amounts of each asset (e.g., out1−in1,out1−in2, and so on) for every asset in the transaction. If out1 has thesame asset tag as one of the inputs, the transaction signer will knowthe secret key corresponding to one of these differences, and be able toproduce the ring signature. The asset surjection proof is thereforedefined as this ring signature.

At step 770, the encrypted received amounts, the encrypted outputvalues, the first ring signatures and the second ring signatures maythen be stored in a block, the block being published on a blockchainwhere it may be subsequently verified. This signifies completion of oneside of the transaction (much as step 160 in FIG. 1). To facilitatecompletion of the transaction, in some embodiments at least onerangeproof includes a message from a sender of the first asset and thesecond asset. The message may include the first blinding value, thesecond blinding value, and, for each asset sent, the difference betweenthe first blinding value and the output coefficient. As is discussedbelow, the message may be used by a receiver of the first asset and thesecond asset to verify completion of a transaction.

In a multi-asset chain, it may make sense in some contexts for assets ofa specific type to be created or destroyed. This may be accomplishedusing issuance transactions on the blockchain ledger, which create newasset tags and a specified amount of this asset. FIG. 8 shows a flowdiagram for an issuance transaction 800 on a blockchain creating a newasset class, in an embodiment. The issuance transaction 800 may beinitiated by receiving a request to issue a specified amount of a firstasset class at step 810. An associated asset tag corresponding to thenew asset class may then be determined at 820, the determined asset tagbeing a selected point on a uniformly random elliptic curve used for allasset tags. The selected point may be selected such that the selectedpoint cannot be algebraically derived from any other point correspondingto an existing asset tag.

As mentioned above, the asset tag for an asset is an element H_(A)∈Gobtained by execution of the Pedersen commitment Setup using anauxiliary input A. In the context of a blockchain, it is desirable toensure that any input A is used only once to ensure assets cannot beinflated by means of multiple independent issuances. Associating anissuance with the spend of a UTXO, and a maximum of one issuance perspecific UTXO may achieve this uniqueness property. The unambiguousreference to the UTXO being spent is hashed together with aissuer-specified value, the Ricardian contract hash, to generate theauxiliary input A to the Pedersen commitment. See Grigg, I.: TheRicardian contract. In: First IEEE International Workshop on ElectronicContracting. IEEE (2004), which is hereby incorporated by reference.Given an input being spent I, itself an unambiguous reference to anoutput of another transaction, and the issuer-specified Ricardiancontract C, the asset entropy E is defined as Hash(Hash(I)∥Hash(C)). TheRicardian contract is a machine parseable legal document specifying theconditions for use, and especially redemption of the asset being issued.The hash of the Ricardian contract C may be an irrevocable committmentto the issuance of the asset. Given an asset entropy E, the asset tag isthe element H_(A)∈G obtained by execution of the Pedersen commitmentSetup using Hash(E∥0) as the auxiliary input. Every non-coinbasetransaction input can have associated with it up to one new assetissuance.

An asset issuance input may include an UTXO spend I (interpreted as anon-issuance input of the same transaction); a Ricardian contract C; aninitial issuance explicit value v₀ or Pedersen commitment H andrangeproof Po; and a Boolean field indicating whether reissuance isallowed. The determined asset tag and the requested amount may then bestored in an issuance block and subsequently published on the blockchainat step 830. Issuance tokens may be created alongside a given assettype, or not, if the asset should not support reissuance. Issuancetransactions may be unique in that they are not required to balance tozero. However, if they issue a public amount, it is still verifiablethat exactly this amount, no more and no less, was actually issued.

Assets may be either of fixed issuance or, optionally, permit laterreissuance using an asset reissuance capability. This capability is atoken providing its owner with the ability to change the amount of assetin circulation at any point after the initial issuance. When areissuable asset is created, both the initial asset issuance and thereissuance capability token are generated at the same time. Laterreissuance may be done by proving authority over reissuance tokens,which are related (but distinct) assets. Given an asset entropy E, theasset reissuance capability is the element H_(A)∈G obtained by executionof the Pedersen commitment Setup using Hash(E∥1) as the auxiliary input.An asset which supports reissuance indicates this in its asset issuanceinput, and the transaction contains an additional output of amount 1which commits to asset tag H_(A). Note the parallel to the definition ofthe asset tag given above, but with the concatenation of a differentconstant before hashing. In this way an asset tag is linked to itscorresponding reissuance capability, and the holder of such a capabilityis able to assert their reissuance right simply by revealing theblinding factor for the capability along with the original assetentropy.

An asset reissuance input may include a spend of a UTXO containing anasset reissuance capability; the original asset entropy E; the blindingfactor for the asset commitment of the UTXO being spent; and either anexplicit reissuance amount vi, or Pedersen commitment H and rangeproofPi. This reissuance mechanism is a specific instance of a generalcapability-based authentication scheme. It is possible to use the samescheme to define capabilities that gate access to other restrictedoperations, or use separate capabilities for increasing and decreasingissuance, and explicit vs committed reissuance amounts. In general, theright being protected could even be made extensible by making thecommitment generator the hash of a script that validates the spendingtransaction.

To prove that the asset commitments associated to outputs commit tolegitimately issued asset tags, asset surjection proofs are used abovewhich show that outputs commit to the same asset tag as some input (ifthose inputs are outputs of previous transactions, they have assetsurjection proofs showing the same thing, and so on until the processterminates at an asset issuance input which has an explicit asset tag).This allows confidential assets to work on a blockchain which supportsindefinitely many asset types, which may be added after the chain hasbeen defined. An alternate scheme, which may be used for a small fixedset of asset tags, is to define the asset tags at the start of thechain, and to have each output include an asset surjection proof to theglobal list of asset tags. The fixed list of asset tags (having ablinding factor of zero) may be used in place of the list of receivedasset tags (corresponding to the asset types in the transaction).Instead of using the difference between the blinding factors to sign thesecond ring signature, this means only the output blinding factors areused to sign the second ring signature. The alternate scheme may bereferred to as “small assets” and the more general scheme describedabove as “big assets.” It is also possible to do an intermediate scheme,by having a global dynamic list of assets with each transactionselecting a subset of asset tags which its outputs have an assetsurjection proof to. In general, there is room to adapt this scheme foroptimal tradeoff between asset surjection proof size and privacy forspecific use cases. The small assets solution is advantageouslycompatible with Mimblewimble, an extension to confidential transactionswhich improves privacy and scaling by removing information from thetransaction graph, while big assets is not. See T. E. Jedusor,Mimblewimble, 2016, Defunct hidden service,http://5pdcbgndmprm4wud.onion/mimblewimble.txt. Reddit discussion athttps://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimblenoninteractive_coinjoin_and_better/, and Poelstra, Andrew, Mimblewimble,2016, https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.pdf,which are hereby incorporated by reference

Verification of a confidential assets transaction may be similar to theverification of a confidential transaction shown in FIG. 4. For example,FIG. 9 shows a flow diagram for a method 900 of verifying an encryptedtransaction on a blockchain involving different asset types, in anembodiment. For each asset type, the encrypted received amount, theencrypted output value, first ring signature, and second ring signatureare received in a block appended to the blockchain at step 910. At step915, the first ring signature and second ring signature are verified,and verification is denied when either ring signature failsverification. The encrypted received amount and the encrypted outputvalue are extracted from the received block at step 920. The encryptedreceived amount, as described above, includes an amount received of anasset, a blinded asset tag associated with the asset type and a secondblinding value. The blinded asset tag includes a first blinding value,and the encrypted output value includes an associated blinding amount.The transaction is verified at step 930 if the sum of the encryptedinput value and the encrypted output value is zero, and the transactionis denied verification if the sum of the encrypted input value and theencrypted output value is a nonzero value at step 940.

As for the recipient of the asset having the input value, the amountsand asset types may be decrypted using a private key held by therecipient. The block may be retrieved from the blockchain, by therecipient using a separately-received address. The first ring signature,generated during the encryption process may be regenerated using aprivate key (e.g., of the recipient). The ring signature may beassociated with a correctly-valued public key for each digit of theencrypted input value, in addition to a plurality of incorrectly-valuedpublic keys for each digit. The correctly-valued public key may beselected from a group of, for example, four public keys for each digitof the encrypted input value. An XOR operation may be applied to eachdigit of the ring-encrypted input value, starting with the smallestdigit. The applying the XOR operation may be repeated for each digit ofthe encrypted input value. A repeated pattern within an output of theXOR operation may be identified. The positions of the repeated patternwithin the output of the XOR operation may then be used to determine thereceived amount of an asset from the encrypted output value.

To further elaborate the storing and verification of transactionsinvolving confidential amounts and confidential asset types, FIGS. 10A-Bshow simplified block diagrams of a chain of digital signatures 1000 ofa plurality of transactions and a proof-of-work system 1050,respectively, according to various embodiments. In the digital signaturechain 1000, each owner transfers amounts of the assets to the next ownerby digitally signing a hash of the previous transaction involving theassets and the public key of the next owner, and adding these to the endof each asset. A payee can verify the transferred signatures to verifythe chain of ownership, thus showing the asset to be legitimate. Forexample, in transaction 1015, the transferring owner, Owner 1, digitallysigns hash 1028 of previous transaction 1010 involving the transferredasset and the public key 1030 of Owner 2, the recipient of the asset, toproduce a signature for Owner 2 1032 at step 1024. To perform the stepof verifying the signature, Owner 2 may use Owner 1's public key 1034 atverification step 1022. Subsequent transaction 1020 may be implementedin the same fashion as transaction 1015.

To assist in making sure a previous owner of an asset did not transactthe same asset twice, a proof of work system 1050 may be implemented oneach block in a ledger. For an exemplary timestamp scheme, theproof-of-work may be implementing by incrementing a nonce (number usedonce, a conventional cryptographic concept) 1055 in the block 1060 untila value is found that gives the block's previous hash 1065 the requiredzero bits initially recorded with the asset. As seen in system 1050(implemented on a blockchain server, for example,), each block 1060 alsoincludes the first and second ring signatures, encrypted asset tag, andencrypted output amount 1070 stored on the blockchain ledger, asdiscussed above.

What is claimed is:
 1. A method for encrypting amounts and asset typestransacted on a blockchain ledger, the method comprising: receiving, bya processor, a first amount of a first asset and a second amount of asecond asset to be transacted, each asset having an associated assettag, the associated asset tags being uniformly random elliptic curvepoints whose discrete logarithms are not known with respect to eachother; adding, by the processor, a first blinding value to each assettag transacted, thereby creating blinded asset tags for each of thefirst asset and the second asset, the blinded asset tags being uniformlyrandom elliptic curve points; multiplying, by the processor, the firstamount by the first blinded asset tag and the second amount by thesecond blinded asset tag, the product of each multiplication being ablinded asset amount; adding, by the processor for each received asset,a second blinding value to each blinded asset amount that is transacted,thereby creating encrypted amounts of the first asset and the secondasset; generating, by the processor, an output value corresponding toeach received amount of the received assets; encrypting, by theprocessor, the generated output values to create encrypted outputvalues, each encrypted output value including a determined outputblinding amount such that the first blinding value and the output valueblinding amount of an asset cancel each other out when added together,wherein both the received amounts and the generated output values foreach asset fall within a value range, the value range being defined sothat a sum of any two values within the range does not exceed anoverflow threshold, a sum of the encrypted amounts and encrypted outputvalues for each asset equaling zero; generating, by the processor, aplurality of rangeproofs for each received asset, wherein differentrangeproofs are associated with each of the generated output values, therangeproofs showing that the value associated with the rangeproof fallswithin the value range, each rangeproof being associated with adifferent public key; signing each public key, by the processor, with afirst ring signature based on a public key of a recipient, therebyencrypting the plurality of rangeproofs, wherein a single memory amountis shared among each public key; generating, by the processor,differences between the output values and the received amounts of eachasset; signing the differences for each asset, by the processor, with asecond ring signature having a difference between the first blindingvalue and an output coefficient as a private key, thereby encrypting thedifferences into an asset surjection proof; and storing, by theprocessor, the encrypted amounts, the encrypted output values, the firstring signatures, and the second ring signatures in a block, the blockfurther comprising a digital signature signed using a private keyassociated with a prior owner, the digital signature comprising a hashof a previous transaction value retrieved from a server over a networkfrom a blockchain stored on the server, the previous transaction valuebeing stored on the server in a prior block; and transmitting, by theprocessor, the block over the network connection to the server storingthe blockchain, the block being subsequently published on theblockchain.
 2. The method of claim 1, wherein at least one rangeproofcomprises a message from a sender of the first asset and the secondasset, the message comprising the first blinding value, the secondblinding value, and, for each asset sent, the difference between thefirst blinding value and the output coefficient, the message being usedby a receiver of the first asset and the second asset to verifycompletion of a transaction.
 3. The method of claim 1, furthercomprising performing an issuance transaction to establish the firstasset on the blockchain ledger, the issuance transaction comprising:receiving a request to issue a specified amount of the first assetclass; determining the associated asset tag corresponding to the newasset class, the determined asset tag being a selected point on auniformly random elliptic curve used for all asset tags, the selectedpoint being selected such that the selected point can not bealgebraically derived from any other point corresponding to an existingasset tag; and storing the determined asset tag and specified amount ina issuance block, the issuance block being subsequently published on theblockchain.
 4. The method of claim 3, further comprising providing, inresponse to the request to issue the first asset class, a reissuancetoken for the first asset class, the reissuance token generatingadditional amounts of the first asset class when submitted with asubsequent request to reissue the first asset class.
 5. The method ofclaim 1, wherein each value range is set by a sender of the first amountand the second amount.
 6. The method of claim 1, the signing of thefirst ring signature for each asset comprising; assigning each digit inthe received amount of each asset to a ring, each ring having aplurality of public keys corresponding to possible values of the digit;encrypting each digit using a digit-specific blinding factor; assigninga potential value for the digit to a public key for that digit; andgenerating the ring signature using a private key, the ring signaturebeing associated with a correctly-valued public key for each digit. 7.The method of claim 6, further comprising rewriting the input value intobase four, wherein each digit in the rewritten input value is assignedto a ring having four public keys corresponding to possible values ofthe digit.
 8. The method of claim 6, further comprising rewriting theinput value a floating point value with a base ten exponent, therebyreducing the number of digits in the input value.
 9. The method of claim1, wherein the block further includes an unencrypted fee associated withthe transaction.
 10. The method of claim 1, wherein the public key is anelliptic curve cryptography pubkey that uses two generators, wherein thefirst generator and second generator are discrete logs of each other.11. The method of claim 1, the processor further receiving amounts ofthree or more assets, wherein the method of claim 1 is applied to eachreceived asset.
 12. A method for verifying an encrypted transactionhaving a plurality of different assets being transacted on a blockchainledger, the method comprising, for each received asset type: receiving,by a processor of a computer system in communication via a networkconnection with a server storing the blockchain ledger, an encryptedreceived amount, an encrypted output value, a first ring signature, anda second ring signature in a block appended to the blockchain, the blockfurther comprising a digital signature signed using a private keyassociated with a prior owner, the digital signature comprising a hashof a previous transaction value stored on the blockchain ledger in aprior block; verifying, by the processor, that the digital signature isvalid using a public key associated with the prior owner, the public keybeing part of key pair with the private key associated with the priorowner, wherein verification is denied if the digital signature cannot bevalidated using the public key associated with the prior owner;verifying, by the processor, the first ring signature and second ringsignature, wherein verification is denied if either ring signature failsverification; extracting the encrypted received amount and the encryptedoutput value from the received block, the encrypted received amountcomprising an amount received of an asset, a blinded asset tagassociated with the asset type and a second blinding value, the blindedasset tag comprising a first blinding value, and the encrypted outputvalue comprising an associated blinding amount; verifying thetransaction if the sum of the encrypted received amount and theencrypted output value for the asset is zero; and denying verificationto the transaction if the sum of the encrypted received amount and theencrypted output value for the asset is a nonzero value.
 13. A methodfor decrypting amounts and assets transacted on a blockchain ledger, themethod comprising: using a separately-received address to retrieve ablock from a blockchain, the block comprising a plurality of assettypes, the block further comprising, for each asset type, an encryptedreceived amount, an encrypted output value, a first ring signature, anda second ring signature, the block being retrieved via a networkconnection from a server storing the blockchain, the block furthercomprising a digital signature signed using a private key associatedwith a prior owner, the digital signature comprising a hash of aprevious transaction value retrieved from a server over a network from ablockchain stored on the server, the previous transaction value beingstored on the server in a prior block; for each asset type of the block:using a private key to access the first ring signature, the first ringsignature being associated with a correctly-valued public key for eachdigit of the encrypted received amount, the correctly-valued public keybeing selected from a group of four public keys for each digit of theencrypted received amount of the asset, the private key corresponding toa second blinding value; applying an XOR operation to the smallest digitof the encrypted received amount of the asset; repeating the applyingthe XOR operation to each digit of the encrypted received amount of theasset; identifying a repeated pattern within an output of the XORoperation; using the positions of the repeated pattern within the outputof the XOR operation to determine the received amount from the encryptedreceived amount of the asset; using a difference between a firstblinding value and an output coefficient to access the second ringsignature, the second ring signature being associated with a key valuefor each digit of a blinded asset tag.
 14. The method of claim 13, thefirst ring signature of each asset comprising a plurality ofrangeproofs, wherein at least one rangeproof comprises a message from asender of the first asset and the second asset, the message comprisingthe first blinding value, the second blinding value, and, for each assetsent, the difference between the first blinding value and the outputcoefficient, the message being used by a receiver of the first asset andthe second asset to verify completion of a transaction.
 15. A method forencrypting an amount transacted on a blockchain ledger, the methodcomprising: adding, by a processor, a blinding amount to an input valuebeing transacted, thereby created an encrypted input value; generating,by the processor, an output value corresponding to the input value;encrypting, by the processor, the generated output value to create anencrypted output value, the encrypted output value including acorresponding blinding amount such that the input value blinding amountand the generated output value blinding amount cancel each other outwhen added together, wherein both the input value and the output valuebeing transacted are values falling with a value range, the value rangebeing defined so that a sum of any two values within the range does notexceed an overflow threshold, a sum of the encrypted input value and theencrypted output value equaling zero; generating, by the processor forthe encrypted output value, a plurality of rangeproofs, the rangeproofsshowing that the input value falls within the value range, eachrangeproof being associated with a different public key, the generatingcomprising: converting, by the processor, each rangeproof into aplurality of scalar values, each scalar value having a predeterminednumber of decimal places; setting for each plurality of scalar values,by the processor, a selected scalar to zero; normalizing, by theprocessor, the remainder of each plurality of scalar values based on anoriginal value of the selected scalar, thereby reducing a number of eachplurality of scalar values by one; completing, by the processor, theplurality of rangeproofs using the normalized scalar values; signingeach public key, by the processor, with a ring signature based on apublic key of a recipient, thereby encrypting the remainder of theplurality of rangeproofs, wherein a single memory amount is shared amongeach public key; storing, by the processor, the encrypted input value,the encrypted output value, and the encrypted rangeproofs in a block,the block further comprising a digital signature signed using a privatekey associated with a prior owner, the digital signature comprising ahash of a previous transaction value retrieved from a server over anetwork from a blockchain stored on the server, the previous transactionvalue being stored on the server in a prior block; and transmitting, bythe processor, the block over a network connection to a server storing ablockchain, the block being subsequently published on the blockchain.